1. Technical Field
The present invention relates to the field of software and, more particularly, to Web portals.
2. Description of the Related Art
Many Web sites utilize portals, which are anchor Web pages used as entry points or gateways to network accessible information. More specifically, a portal can include one or more containers within which externally derived content can be placed. For example, a portal can extract data from a content source, which can be a Web page. Portals, having the ability to group data from diverse and independently maintained sites, can be highly efficient structures for providing information to users. Since software development and maintenance can be extremely costly, leveraging pre-existing software from content sources within portal containers can save businesses considerable resources.
Portal construction is possible due to the extensive use of markup within network assessible documents. Markup refers to the sequence of characters or other symbols that can be inserted at certain places in an electronic document to indicate how the electronic document should look when the document is printed or displayed. Markup can also define logical structures, such as a table, a graphic element, and/or a data field, within an electronic document. Numerous standard markup languages exist that include, but are not limited to, HTML (Hypertext Markup Language), XML (Extensible Markup Language), SGML (Standard Generalized Markup Language), WML (Wireless Markup Language), and the like. Network accessible markup documents can generally be accessed and displayed using a Web browser, which can be a client program that utilizes the hypertext transfer protocol (HTTP) to make requests of servers for specified documents, usually markup documents.
Problems can occur with portals incorporating external content into containers because conventional markup languages lack variable type checking capabilities. Type checking is a software engineering concept referring to the testing for type compatibility between two variables. Type checking assures that only integer values are assigned to integer variables, only string values are assigned to string variables, only graphics assigned to graphic variables, and the like. Portal containers can be thought of as a particular type of object, a container object, that accepts values or content from the content source. Conventionally, markup code representing content is directly inserted into a container without any verification that the content is compatible with the container.
Notably, a container can be embedded within a defined structure of the portal. The defined structure can have content restrictions and structural restrictions associated with it. For example, the container can be a graphical frame intended to receive a digitally rendered graphical image, such as a GIF (Graphics Interchange Format) or a .JPEG (Joint Photographic Experts Group) file. In such an instance, content input should be limited to graphical images. Similarly, the container can be a text box into which a graphical image should not be inserted. In another example, content can contain formatting details that are incompatible with the container, such as attempting to display a white colored string within a container with a white background.
Often, portal designers are more interested in excluding a few select structures from a container than limiting a container to a tightly defined set of data types. Thus, a form of “structural exclusion checking” as opposed to true type checking would be valuable to portal designers. Structural exclusion checking can prevent numerous anomolies from occurring when restricted content or structures are inadvertently included within the container. The anomolies can result in run-time error messages, improperly formatted output, browser lock-up, and operating system crashes.
For example, a container may represent a cell within a table of a portal. While the insertion of a wide variety of variable types, such as graphics, sound, multimedia objects, text, and hyperlinks, into the container may be appropriate, a limited number of structures can be restricted. For example, a portal developer may wish to restrict the insertion of a table row into the container, which can result in undesirable formatting.
Conventional solutions to the aforementioned problem have proven inadequate. The most common conventional solution involves modification of a DTD (Document Type Definition) associated with a markup language document. Particularly, a DTD document can be constructed so that structures within a particular markup language will behave in non-standard ways. For example, a structure normally specifying a table row (TR) can be redefined within a DTD to have no functionality. When so defined, a markup tag specifying a table row structure is effectively ignored. Redefining a DTD violates standards, causes behavior fraught with potential errors and side effects, and is generally a disfavored technique from a structured programming viewpoint. Even if this solution were otherwise adequate, which it is not, DTD features vary from markup language to markup language. Thus, any DTD related solution is restricted to a particular markup language and cannot be applied generally.